docs: content audit remediation and site rework#400
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 18 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe PR updates the documentation site across shared UI, styling, architecture, and Python, Node, and Java content. It adds SDK-aware TOC behavior, interactive diagrams, sticky tables, revised landing content, expanded API references, workflow guidance, operational documentation, and SDK-scoped FAQ examples. ChangesDocs-site experience
Java documentation
Node documentation
Python documentation
Estimated code review effort: 5 (Critical) | ~120 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 11
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
docs/app/components/docs/toc.tsx (1)
53-64: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winClear stale headings on an initially empty SDK scan.
When the newly selected SDK has no visible
h2/h3headings, bothkeyand the initiallastKeyare""; the function returns beforesetHeadings([]), leaving the previous SDK’s TOC visible.Proposed fix
- let lastKey = ""; + let lastKey: string | null = null; const key = next.map((h) => h.id).join("|"); - if (key === lastKey) { + if (lastKey !== null && key === lastKey) { return; }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/app/components/docs/toc.tsx` around lines 53 - 64, Update the scan function in the TOC component so an initially empty heading scan still clears stale state: do not return solely because key equals lastKey when next is empty, or otherwise ensure setHeadings([]) runs for the empty SDK result before returning. Preserve the existing deduplication behavior for non-empty scans and continue disconnecting the spy when no headings exist.docs/content/docs/resources/faq.mdx (1)
514-544: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winRemove the
0 = allwording. These purge APIs take an older-than cutoff (seconds in Python, ms in Node/Java), sopurgeCompleted(0)/purgeDead(0)won’t delete normal jobs. Use a real cutoff or rephrase the examples.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/resources/faq.mdx` around lines 514 - 544, Update the FAQ purge examples for the Python, Node, and Java SDK sections to remove the inaccurate “0 = all” wording and avoid implying that zero purges normal jobs; use a valid older-than cutoff that represents the intended retention period, and ensure the comments describe the units correctly for each SDK.docs/content/docs/python/guides/integrations/django.mdx (1)
87-95: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winMake the example use the same storage configuration as Django.
The full example creates
Queue(db_path="taskito.db"), butget_queue()usesTASKITO_*settings. Without explicitly aligning these values, the worker and admin can operate on different databases, producing empty or inconsistent admin views.Also applies to: 110-118
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/guides/integrations/django.mdx` around lines 87 - 95, Update the Django integration example’s queue initialization and get_queue() configuration to use the same TASKITO_* settings and database path, ensuring the worker CLI, tasks, and admin all share one storage configuration.docs/content/docs/python/more/examples/batch-emails.mdx (1)
93-101: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winKeep the
chunks()API consistent throughout the example.The prose says
canvas.chunks(), while the code imports and callschunks()directly fromtaskito. Update the prose or change the code so readers receive one canonical API.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/more/examples/batch-emails.mdx` around lines 93 - 101, The example uses inconsistent `chunks()` APIs: prose references `canvas.chunks()` while the code imports and calls `chunks()` directly. Update the “When to use chunks() instead” prose to describe the direct `chunks()` API, or revise the import and invocation to consistently use `canvas.chunks()` throughout.
🟡 Minor comments (29)
docs/content/docs/resources/comparison.mdx-142-142 (1)
142-142: 🚀 Performance & Scalability | 🟡 Minor | ⚡ Quick winClarify the GIL row The Rust side only avoids GIL contention during scheduling and dispatch; worker threads still acquire the GIL to run Python task code, so this row should say that explicitly.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/resources/comparison.mdx` at line 142, Update the GIL row in the comparison table to clarify that Rust avoids GIL contention only during scheduling and dispatch, while worker threads still acquire the GIL when executing Python task code; revise the Rust-side wording accordingly without changing the Python-side comparison.docs/content/docs/architecture/job-lifecycle.mdx-12-17 (1)
12-17: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winAdd the
Failedstep to the lifecycle text. The status table and diagram already defineFailed, but this paragraph skips it and jumps fromRunningtoPending/Dead. Update it to show the retry/dead-letter path throughFailed.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/architecture/job-lifecycle.mdx` around lines 12 - 17, Update the job lifecycle paragraph to include the Failed status between Running and the retry outcome: when the task raises, transition to Failed, then return to Pending during retry backoff if attempts remain, or move to Dead and the dead-letter queue when max_retries is exhausted. Preserve the existing Pending-to-Cancelled path.docs/content/docs/architecture/failure-model.mdx-8-12 (1)
8-12: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winQualify the dispatch guarantee.
claim_executionprevents duplicate dispatch, but it doesn’t rule out overlap across timeout-based retries. Call this exactly-once dispatch, not no-overlap execution.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/architecture/failure-model.mdx` around lines 8 - 12, Qualify the guarantee described in the failure-model documentation: update the `claim_execution` explanation to state that it prevents duplicate dispatch under normal claiming, but timeout-based retries may overlap, so it does not guarantee no-overlap execution. Retain the distinction between exactly-once dispatch and at-least-once task execution.docs/app/routes/home.tsx-55-59 (1)
55-59: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winMatch the rendered section order to the landing-page objective.
The current JSX renders
HowItWorksbeforeScenarioFinder, while the stated change requiresScenarioFinderto appear first. Swap these two elements if that ordering is intentional.Proposed fix
- <HowItWorks /> <ScenarioFinder /> + <HowItWorks />🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/app/routes/home.tsx` around lines 55 - 59, Swap the JSX order of the HowItWorks and ScenarioFinder components in the page render so ScenarioFinder appears immediately after Hero, followed by HowItWorks.docs/content/docs/java/more/examples/saga-checkout.mdx-69-72 (1)
69-72: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winAvoid implying that pending jobs are permanently stalled.
An unclaimed job remains pending until a worker claims it; it can still progress if the worker starts later. Replace “an unclaimed job never progresses” with wording such as “does not progress until a worker claims it,” and explain that the worker must start before the await timeout expires.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/java/more/examples/saga-checkout.mdx` around lines 69 - 72, Update the saga checkout documentation near the worker startup guidance to avoid stating that unclaimed jobs never progress; explain that a job remains pending until a worker claims it and that the worker must start before the await timeout expires. Preserve the references to the worker registration and run.await behavior.docs/content/docs/java/guides/workflows/conditions.mdx-28-33 (1)
28-33: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winClarify the timeout behavior of
run.await(...).
WorkflowRun.await(...)polls until a terminal state and throws when its timeout expires. Without a tracking worker, the run remainsPENDINGduring that period; it does not wait forever from the caller’s perspective. Say thatawaiteventually times out unless a tracking worker starts.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/java/guides/workflows/conditions.mdx` around lines 28 - 33, Update the warning callout describing WorkflowRun.await(...) to clarify that it polls until a terminal state and throws when its timeout expires; without a tracking worker, the run remains PENDING only until that timeout, rather than waiting forever from the caller’s perspective. State that await eventually times out unless a tracking worker starts.docs/content/docs/java/more/examples/saga-checkout.mdx-81-100 (1)
81-100: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winMake the
Running itexample self-containeddocs/content/docs/java/more/examples/saga-checkout.mdx:81-100
Wrap this in amain/method or mark it as an application fragment; the top-leveltryand undeclaredorder,inventory,payments, andshippingsymbols make it non-compilable as shown.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/java/more/examples/saga-checkout.mdx` around lines 81 - 100, Make the “Running it” example explicitly self-contained by wrapping the existing Taskito/Worker try-with-resources block in a compilable main method or clearly labeling it as an application fragment. Ensure the example declares or initializes order, inventory, payments, and shipping before calling Checkout.submit, and include any required imports or surrounding class context.docs/content/docs/java/guides/integrations/spring.mdx-94-94 (1)
94-94: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winClarify the dashboard-port wording.
The documented default is correct, but “defaults off Spring Boot’s own
8080” is awkward and may obscure that8080remains a valid explicit override.Proposed wording
-| `taskito.dashboard.port` | `int` | `8081` | Bind port (`0` for ephemeral); defaults off Spring Boot's own `8080` | +| `taskito.dashboard.port` | `int` | `8081` | Bind port (`0` for ephemeral); defaults to `8081` rather than Spring Boot's own `8080` |🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/java/guides/integrations/spring.mdx` at line 94, Clarify the description for `taskito.dashboard.port` in the configuration table: state that its default is `8081`, while `8080` remains available as an explicit override, using clear wording instead of “defaults off Spring Boot’s own `8080`.”docs/content/docs/java/guides/core/workers.mdx-24-31 (1)
24-31: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winDescribe
@Asyncas asynchronous dispatch, not inline execution.
@Asyncdoes not run the method inline on the caller’s thread; it submits execution to a Spring-managed executor. Clarify this distinction to avoid misleading users about call and scheduling behavior.Proposed wording
- `@Async` runs the call inline on a Spring-managed thread pool the moment - it's invoked — there's no separate producer/consumer step, and queued calls + `@Async` dispatches the call to a Spring-managed thread pool when it's + invoked — there's no separate durable producer/consumer step, and queued calls🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/java/guides/core/workers.mdx` around lines 24 - 31, Update the “Coming from Spring `@Async`?” callout to accurately state that `@Async` submits the method to a Spring-managed executor and returns without running it on the caller’s thread; contrast this asynchronous dispatch with a Worker’s separately started process or thread and durable polling behavior.docs/content/docs/node/api-reference/workflows.mdx-37-40 (1)
37-40: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winDefine
runIdin the example.The standalone snippet references an undeclared identifier, so it cannot be copied into TypeScript as shown.
Proposed fix
+const runId = "nightly-etl"; const workflow = queue.workflows.define("etl").step("extract", "extract"); const run = queue.workflows.submit(workflow, { queueDefault: "io", params: { runId } });🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/node/api-reference/workflows.mdx` around lines 37 - 40, Define `runId` before it is used in the workflow submission example, using a representative string or generated identifier so the standalone TypeScript snippet is valid and copyable.docs/content/docs/node/getting-started/concepts.mdx-18-19 (1)
18-19: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winQualify SQLite as the default backend.
The following callout supports Postgres and Redis via a DSN, so “all live in one embedded SQLite file” is not true for every deployment.
Proposed fix
- The queue, job results, and cron schedules all live in one embedded - SQLite file — nothing extra to install or operate. + By default, the queue, job results, and cron schedules live in one embedded + SQLite file — nothing extra to install or operate.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/node/getting-started/concepts.mdx` around lines 18 - 19, Update the documentation near the embedded SQLite description to qualify SQLite as the default backend, and note that deployments can instead use Postgres or Redis configured through a DSN. Avoid stating that all queues, results, and schedules always live in SQLite.docs/content/docs/node/guides/workflows/fan-out.mdx-44-48 (1)
44-48: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winScope the BullMQ comparison to a single
FlowProducer.add(...)call.childrenis fixed per flow submission, but BullMQ can still add child jobs later from a worker withqueue.add(..., { parent }).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/node/guides/workflows/fan-out.mdx` around lines 44 - 48, Clarify the BullMQ comparison in the fan-out documentation by scoping the fixed `children` limitation to a single `FlowProducer.add(...)` submission. Acknowledge that BullMQ workers can add additional child jobs later via `queue.add(..., { parent })`, while preserving the distinction that taskito derives child count dynamically from `list` at runtime.docs/content/docs/node/guides/reliability/locks.mdx-50-54 (1)
50-54: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winQualify the BullMQ lock comparison.
BullMQ’s normal worker lock is internal and job-scoped, but the public
Job.extendLock(token, duration)API is callable by application code during manual processing. Keep the distinction that BullMQ does not provide a general-purpose application lock, rather than saying its lock cannot be called from application code. (docs.bullmq.io)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/node/guides/reliability/locks.mdx` around lines 50 - 54, Update the “Coming from BullMQ?” comparison to acknowledge BullMQ’s public Job.extendLock(token, duration) API for manually processed jobs, while clarifying that its normal lock is internal and job-scoped and BullMQ does not offer a general-purpose application-level lock.docs/content/docs/node/guides/reliability/retries.mdx-6-8 (1)
6-8: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winMention non-retryable failures.
The supplied
crates/taskito-core/src/scheduler/result_handler.rs:52-120path sends failures withshould_retry === falsedirectly to the DLQ before checking the retry budget. Change “A task that throws” to “A retryable task failure” and mention exception filtering.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/node/guides/reliability/retries.mdx` around lines 6 - 8, Update the retry behavior description to say “A retryable task failure” instead of “A task that throws,” and mention that exception filtering can mark failures as non-retryable. Clarify that failures with should_retry === false are sent directly to the dead-letter queue without checking maxRetries, while retryable failures follow the retry budget and exponential backoff.docs/content/docs/node/guides/reliability/idempotency.mdx-19-23 (1)
19-23: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winQualify “permanent reservation.”
A BullMQ
jobIdsuppresses duplicates while an existing job record remains;removeOnComplete,removeOnFail, or explicit removal allows the same ID later. Reword this as record-lifetime deduplication rather than a permanent reservation. (docs.bullmq.io)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/node/guides/reliability/idempotency.mdx` around lines 19 - 23, Update the BullMQ comparison in the idempotency guide to describe custom jobId deduplication as lasting only while the existing job record remains, since removeOnComplete, removeOnFail, or explicit removal permits reuse. Replace “permanent reservation” with wording that contrasts BullMQ’s record-lifetime behavior against taskito’s pending/running uniqueKey scope.docs/content/docs/python/api-reference/queue/index.mdx-93-93 (1)
93-93: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winInclude
BatchConfigin the documentedbatchtype.
docs/content/docs/python/api-reference/batching.mdx:18-25saysBatchConfigis accepted, but this signature and parameter table only advertisebool | dict | None. Align these API references, or explicitly state thatBatchConfigis not valid for@queue.task(batch=...).Proposed documentation fix
- batch: bool | dict | None = None, + batch: bool | dict | BatchConfig | None = None,Also applies to: 120-120
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/api-reference/queue/index.mdx` at line 93, Update the documented batch type in the queue API reference signature and corresponding parameter table to include BatchConfig alongside bool, dict, and None. Keep both occurrences consistent with the batching documentation, unless BatchConfig is explicitly documented as unsupported for `@queue.task`(batch=...).docs/content/docs/python/api-reference/result.mdx-41-45 (1)
41-45: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winFix the broken queue API link.
The supplied API index links the queue reference at
/python/api-reference/queue, while this link targets/python/api-reference/queue/queues, for which no corresponding page is present in the supplied Python API files.-> aggregate count bucket from [`queue.stats()`](/python/api-reference/queue/queues) +> aggregate count bucket from [`queue.stats()`](/python/api-reference/queue)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/api-reference/result.mdx` around lines 41 - 45, Fix the queue API reference link in the naming note by changing its target from `/python/api-reference/queue/queues` to the existing `/python/api-reference/queue` route, without altering the surrounding status terminology.docs/content/docs/python/api-reference/queue/index.mdx-124-129 (1)
124-129: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winDocument
predicate_extrasanddefault_defer_secondsin the@queue.task()API reference
docs/content/docs/python/api-reference/queue/index.mdx:72-129omits these decorator kwargs from the canonical signature and parameter table even though@queue.task()accepts them. Add them alongsidepredicate/on_falsein the main reference.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/api-reference/queue/index.mdx` around lines 124 - 129, Update the `@queue.task`() canonical signature and parameter table in the queue API reference to include predicate_extras and default_defer_seconds alongside predicate and on_false, documenting their purpose and accepted values consistently with the existing task options.docs/content/docs/python/guides/reliability/rate-limiting.mdx-8-9 (1)
8-9: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winMention Redis here too. Rate-limit state is persisted in Redis as well as SQLite and Postgres, so the backend list is incomplete.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/guides/reliability/rate-limiting.mdx` around lines 8 - 9, Update the rate-limiting documentation near the description of persisted rate limits to include Redis alongside SQLite and Postgres. Ensure the backend list accurately states that rate-limit state is persisted in SQLite, Postgres, or Redis.docs/content/docs/python/guides/reliability/retries.mdx-152-164 (1)
152-164: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winWait for completion before reading
job.errors.
delay()returns immediately, so this loop can run before any attempt is recorded. Block onjob.result()and catch the final task exception before iterating over the error history.Proposed fix
job = unreliable.delay() -# After the job exhausts all retries... +try: + job.result(timeout=30) +except ConnectionError: + pass + for error in job.errors:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/guides/reliability/retries.mdx` around lines 152 - 164, Update the retry example to wait for task completion by calling job.result() and catching its final exception before iterating over job.errors; retain the existing attempt-printing logic and clarify that errors are read only after completion.docs/content/docs/python/getting-started/concepts.mdx-16-23 (1)
16-23: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winQualify the queue architecture claim. Celery, RQ, Dramatiq, and Huey don’t all require separate broker and result-backend services; some share storage, and Huey can run on SQLite without an extra service. Reword this as “often need an external broker and may use a separate result backend.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/getting-started/concepts.mdx` around lines 16 - 23, Revise the introductory architecture description in the concepts documentation to avoid claiming that all listed Python task queues require separate broker and result-backend services. Reword it to state that they often need an external broker and may use a separate result backend, while acknowledging shared storage and Huey’s SQLite option; update the accompanying bullets to match this qualified wording.docs/content/docs/python/guides/advanced-execution/unique-tasks.mdx-21-22 (1)
21-22: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winDescribe key release as leaving pending/running, not just completion/DLQ.
docs/content/docs/python/guides/advanced-execution/unique-tasks.mdx:21-22should say the key is freed once the job is no longer pending or running, so it also covers terminal states like cancelled.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/guides/advanced-execution/unique-tasks.mdx` around lines 21 - 22, Update the unique-task explanation near the statement about the original job completing or reaching DLQ: describe the key as being released once the job is no longer pending or running, allowing a new job with the same key after any terminal state, including cancellation.docs/content/docs/python/guides/resources/testing.mdx-12-14 (1)
12-14: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick winQualify the parallel-safety claim.
sdks/python/taskito/testing.py:111-182mutates queue-level state and patches that queue’senqueuemethod. Overlapping contexts that share oneQueuecan interfere, so this is safe for parallel tests only when each test uses a separate queue instance.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/guides/resources/testing.mdx` around lines 12 - 14, Qualify the parallel-safety statement for test_mode(): explain that parallel use is safe only when tests use separate Queue instances, since overlapping contexts sharing a queue can interfere through queue-level state and enqueue patching. Update the surrounding documentation accordingly.docs/content/docs/python/guides/core/scheduling.mdx-65-68 (1)
65-68: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winUpdate the remaining five-field cron example.
This callout correctly establishes taskito’s six-field format, but Line 153 still uses
cron="0 9 * * *"with only five fields. Change it to a six-field expression such ascron="0 0 9 * * *"so the page is internally consistent.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/guides/core/scheduling.mdx` around lines 65 - 68, Update the remaining five-field cron example in the scheduling guide: change the cron argument from "0 9 * * *" to a six-field expression such as "0 0 9 * * *", keeping it consistent with the documented taskito format.docs/content/docs/python/guides/dashboard/rest-api.mdx-13-17 (1)
13-17: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick winQualify readiness and metrics as session-auth-exempt, not unconditionally public.
The server still checks
_metrics_token_ok()for/readinessand/metrics; when metrics-token protection is configured, a sessionless request alone is insufficient. Document that distinction to avoid misleading operators and failing health checks.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/guides/dashboard/rest-api.mdx` around lines 13 - 17, Update the route authentication documentation to qualify `/readiness` and `/metrics` as exempt from session authentication only when their configured metrics-token requirements are satisfied; clarify that sessionless requests alone may be rejected when metrics-token protection is enabled.docs/content/docs/python/guides/dashboard/task-overrides.mdx-59-78 (1)
59-78: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winClarify the persistence wording for
paused.The table at Line 51 calls
Paused“runtime-only,” but this section saysset_task_override(..., paused=True)is recorded and exposed through the dashboard/API. Rename that table text to clarify that it has no decorator equivalent and is currently metadata-only/non-enforced.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/guides/dashboard/task-overrides.mdx` around lines 59 - 78, Update the table’s “Paused” description to clarify that task pause has no decorator equivalent and is persisted or exposed as metadata, but is not enforced by the scheduler. Align the wording with the `queue.set_task_override(..., paused=True)` behavior described in the task-overrides section, avoiding the inaccurate “runtime-only” label.docs/content/docs/python/guides/integrations/fastapi.mdx-64-67 (1)
64-67: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winDocument the wire header name as
x-api-key.Header(...)turnsx_api_keyintox-api-keyby default; useconvert_underscores=Falseonly if the underscore form is intended.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/guides/integrations/fastapi.mdx` around lines 64 - 67, Update the FastAPI integration documentation around require_api_key to explicitly state that the x_api_key parameter maps to the wire header name x-api-key by default; mention convert_underscores=False only if documenting the underscore-form header instead.docs/content/docs/python/more/examples/workflows.mdx-64-65 (1)
64-65: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winWire
accuracy_gateinto the workflow.accuracy_gateis defined but never used;wf.gate("review", ...)is still a manual gate, sodeployis not actually gated onevaluate’spassedresult as the example claims.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/more/examples/workflows.mdx` around lines 64 - 65, The example defines accuracy_gate but does not use it, leaving deploy behind a manual review gate instead of evaluate’s passed result. Update the workflow construction to register accuracy_gate through wf.gate("review", ...) and ensure deploy depends on that gate, removing the manual gate configuration while preserving the ctx.results-based evaluation flow.docs/content/docs/python/guides/operations/testing.mdx-158-176 (1)
158-176: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winMake the chord example self-contained — it relies on
doublefrom the later Chains example, so this block can’t be copied on its own. Definedoublehere or inline a minimal task.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/guides/operations/testing.mdx` around lines 158 - 176, Make the test_chord example self-contained by defining a local double task before it is used, or replacing double with an inline minimal task, while preserving the expected group results and callback assertion.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/app/components/mermaid.tsx`:
- Around line 83-104: Update the mermaid component’s zoom state and portal modal
to implement a focus-managed dialog: add dialog semantics, retain a ref to the
trigger, focus the modal or close control when zoom opens, trap Tab navigation
within the modal, and restore focus to the trigger when zoom closes. Use the
existing zoom click handlers and portal rendering around the mermaid figure to
integrate the focus lifecycle and keyboard handling.
In `@docs/content/docs/java/guides/operations/backends.mdx`:
- Around line 10-14: Update the backend description near the brokerless setup
explanation to clarify that Redis remains required when the Redis backend is
selected. State that Redis serves as the queue’s storage backend and replaces a
separate broker, rather than being optional or unnecessary.
In `@docs/content/docs/node/guides/operations/migration.mdx`:
- Line 20: Update the migration comparison table and surrounding guidance for
`queue.result(id)` to document its default 30-second timeout and that it throws
when the job has not reached a terminal state; clarify that it is not a drop-in
replacement for long-running BullMQ jobs and mention configuring an appropriate
timeout where applicable.
In `@docs/content/docs/node/guides/operations/security.mdx`:
- Around line 44-46: Update the security guidance near the deliverer URL warning
to explicitly require an enforceable egress allowlist for user-controlled
webhook URLs. Document validation and DNS/IP revalidation immediately before
delivery, blocking private, loopback, link-local, metadata, and equivalent
IPv4/IPv6 targets, and restricting or validating redirects so they cannot bypass
these protections.
In `@docs/content/docs/node/guides/reliability/guarantees.mdx`:
- Around line 49-54: Correct the BullMQ comparison text by replacing the
description of QueueEvents as a Redis pub/sub subscriber with a dedicated Redis
Streams consumer, while preserving the explanation that taskito’s queue event
handlers run in the worker process and are not cross-process subscriptions.
In `@docs/content/docs/python/api-reference/saga.mdx`:
- Line 107: Update the terminal-state documentation near
WorkflowState.is_terminal() and WorkflowRun.wait() to include
CompletedWithFailures alongside Completed, Failed, Cancelled, Compensated, and
CompensationFailed, and change the count from five to six.
In `@docs/content/docs/python/getting-started/concepts.mdx`:
- Around line 25-29: Update the documentation paragraph to distinguish SQLite as
the embedded default from Postgres as an externally operated database server,
while preserving that both serve as the broker and result backend without
requiring a separate message broker.
In `@docs/content/docs/python/guides/reliability/guarantees.mdx`:
- Around line 18-20: Revise the exactly-once delivery explanation near the
reliability guarantees content: remove the claim that two-phase commit is
required, and instead describe the acknowledgement/side-effect atomicity gap.
Mention transactional outbox/inbox patterns or idempotency as ways to address
duplicate side effects, while preserving Taskito’s at-least-once delivery
guarantee and guidance to make tasks duplicate-safe.
In `@docs/content/docs/python/guides/resources/dependency-injection.mdx`:
- Around line 145-148: Update both resource factory examples, including
create_db and the corresponding factory near the second referenced example, to
retain the created Engine alongside the sessionmaker and define resource
teardown that calls engine.dispose(). Preserve the injected callable
sessionmaker behavior while wiring explicit cleanup for graceful worker
shutdown.
- Around line 167-174: Move create_engine(...) from module scope into
create_db() so engine construction occurs within the resource lifecycle, then
return sessionmaker(engine) and ensure the teardown for the "db" resource
disposes that created engine instance rather than relying on a module-level
variable.
In `@docs/content/docs/python/guides/resources/proxies.mdx`:
- Around line 158-159: The NoProxy(session) example must not serialize a live
session containing bearer credentials. Replace it with a credential-free session
example or demonstrate a worker-owned injected resource, and remove the
Authorization header before passing any value through process.delay.
---
Outside diff comments:
In `@docs/app/components/docs/toc.tsx`:
- Around line 53-64: Update the scan function in the TOC component so an
initially empty heading scan still clears stale state: do not return solely
because key equals lastKey when next is empty, or otherwise ensure
setHeadings([]) runs for the empty SDK result before returning. Preserve the
existing deduplication behavior for non-empty scans and continue disconnecting
the spy when no headings exist.
In `@docs/content/docs/python/guides/integrations/django.mdx`:
- Around line 87-95: Update the Django integration example’s queue
initialization and get_queue() configuration to use the same TASKITO_* settings
and database path, ensuring the worker CLI, tasks, and admin all share one
storage configuration.
In `@docs/content/docs/python/more/examples/batch-emails.mdx`:
- Around line 93-101: The example uses inconsistent `chunks()` APIs: prose
references `canvas.chunks()` while the code imports and calls `chunks()`
directly. Update the “When to use chunks() instead” prose to describe the direct
`chunks()` API, or revise the import and invocation to consistently use
`canvas.chunks()` throughout.
In `@docs/content/docs/resources/faq.mdx`:
- Around line 514-544: Update the FAQ purge examples for the Python, Node, and
Java SDK sections to remove the inaccurate “0 = all” wording and avoid implying
that zero purges normal jobs; use a valid older-than cutoff that represents the
intended retention period, and ensure the comments describe the units correctly
for each SDK.
---
Minor comments:
In `@docs/app/routes/home.tsx`:
- Around line 55-59: Swap the JSX order of the HowItWorks and ScenarioFinder
components in the page render so ScenarioFinder appears immediately after Hero,
followed by HowItWorks.
In `@docs/content/docs/architecture/failure-model.mdx`:
- Around line 8-12: Qualify the guarantee described in the failure-model
documentation: update the `claim_execution` explanation to state that it
prevents duplicate dispatch under normal claiming, but timeout-based retries may
overlap, so it does not guarantee no-overlap execution. Retain the distinction
between exactly-once dispatch and at-least-once task execution.
In `@docs/content/docs/architecture/job-lifecycle.mdx`:
- Around line 12-17: Update the job lifecycle paragraph to include the Failed
status between Running and the retry outcome: when the task raises, transition
to Failed, then return to Pending during retry backoff if attempts remain, or
move to Dead and the dead-letter queue when max_retries is exhausted. Preserve
the existing Pending-to-Cancelled path.
In `@docs/content/docs/java/guides/core/workers.mdx`:
- Around line 24-31: Update the “Coming from Spring `@Async`?” callout to
accurately state that `@Async` submits the method to a Spring-managed executor and
returns without running it on the caller’s thread; contrast this asynchronous
dispatch with a Worker’s separately started process or thread and durable
polling behavior.
In `@docs/content/docs/java/guides/integrations/spring.mdx`:
- Line 94: Clarify the description for `taskito.dashboard.port` in the
configuration table: state that its default is `8081`, while `8080` remains
available as an explicit override, using clear wording instead of “defaults off
Spring Boot’s own `8080`.”
In `@docs/content/docs/java/guides/workflows/conditions.mdx`:
- Around line 28-33: Update the warning callout describing
WorkflowRun.await(...) to clarify that it polls until a terminal state and
throws when its timeout expires; without a tracking worker, the run remains
PENDING only until that timeout, rather than waiting forever from the caller’s
perspective. State that await eventually times out unless a tracking worker
starts.
In `@docs/content/docs/java/more/examples/saga-checkout.mdx`:
- Around line 69-72: Update the saga checkout documentation near the worker
startup guidance to avoid stating that unclaimed jobs never progress; explain
that a job remains pending until a worker claims it and that the worker must
start before the await timeout expires. Preserve the references to the worker
registration and run.await behavior.
- Around line 81-100: Make the “Running it” example explicitly self-contained by
wrapping the existing Taskito/Worker try-with-resources block in a compilable
main method or clearly labeling it as an application fragment. Ensure the
example declares or initializes order, inventory, payments, and shipping before
calling Checkout.submit, and include any required imports or surrounding class
context.
In `@docs/content/docs/node/api-reference/workflows.mdx`:
- Around line 37-40: Define `runId` before it is used in the workflow submission
example, using a representative string or generated identifier so the standalone
TypeScript snippet is valid and copyable.
In `@docs/content/docs/node/getting-started/concepts.mdx`:
- Around line 18-19: Update the documentation near the embedded SQLite
description to qualify SQLite as the default backend, and note that deployments
can instead use Postgres or Redis configured through a DSN. Avoid stating that
all queues, results, and schedules always live in SQLite.
In `@docs/content/docs/node/guides/reliability/idempotency.mdx`:
- Around line 19-23: Update the BullMQ comparison in the idempotency guide to
describe custom jobId deduplication as lasting only while the existing job
record remains, since removeOnComplete, removeOnFail, or explicit removal
permits reuse. Replace “permanent reservation” with wording that contrasts
BullMQ’s record-lifetime behavior against taskito’s pending/running uniqueKey
scope.
In `@docs/content/docs/node/guides/reliability/locks.mdx`:
- Around line 50-54: Update the “Coming from BullMQ?” comparison to acknowledge
BullMQ’s public Job.extendLock(token, duration) API for manually processed jobs,
while clarifying that its normal lock is internal and job-scoped and BullMQ does
not offer a general-purpose application-level lock.
In `@docs/content/docs/node/guides/reliability/retries.mdx`:
- Around line 6-8: Update the retry behavior description to say “A retryable
task failure” instead of “A task that throws,” and mention that exception
filtering can mark failures as non-retryable. Clarify that failures with
should_retry === false are sent directly to the dead-letter queue without
checking maxRetries, while retryable failures follow the retry budget and
exponential backoff.
In `@docs/content/docs/node/guides/workflows/fan-out.mdx`:
- Around line 44-48: Clarify the BullMQ comparison in the fan-out documentation
by scoping the fixed `children` limitation to a single `FlowProducer.add(...)`
submission. Acknowledge that BullMQ workers can add additional child jobs later
via `queue.add(..., { parent })`, while preserving the distinction that taskito
derives child count dynamically from `list` at runtime.
In `@docs/content/docs/python/api-reference/queue/index.mdx`:
- Line 93: Update the documented batch type in the queue API reference signature
and corresponding parameter table to include BatchConfig alongside bool, dict,
and None. Keep both occurrences consistent with the batching documentation,
unless BatchConfig is explicitly documented as unsupported for
`@queue.task`(batch=...).
- Around line 124-129: Update the `@queue.task`() canonical signature and
parameter table in the queue API reference to include predicate_extras and
default_defer_seconds alongside predicate and on_false, documenting their
purpose and accepted values consistently with the existing task options.
In `@docs/content/docs/python/api-reference/result.mdx`:
- Around line 41-45: Fix the queue API reference link in the naming note by
changing its target from `/python/api-reference/queue/queues` to the existing
`/python/api-reference/queue` route, without altering the surrounding status
terminology.
In `@docs/content/docs/python/getting-started/concepts.mdx`:
- Around line 16-23: Revise the introductory architecture description in the
concepts documentation to avoid claiming that all listed Python task queues
require separate broker and result-backend services. Reword it to state that
they often need an external broker and may use a separate result backend, while
acknowledging shared storage and Huey’s SQLite option; update the accompanying
bullets to match this qualified wording.
In `@docs/content/docs/python/guides/advanced-execution/unique-tasks.mdx`:
- Around line 21-22: Update the unique-task explanation near the statement about
the original job completing or reaching DLQ: describe the key as being released
once the job is no longer pending or running, allowing a new job with the same
key after any terminal state, including cancellation.
In `@docs/content/docs/python/guides/core/scheduling.mdx`:
- Around line 65-68: Update the remaining five-field cron example in the
scheduling guide: change the cron argument from "0 9 * * *" to a six-field
expression such as "0 0 9 * * *", keeping it consistent with the documented
taskito format.
In `@docs/content/docs/python/guides/dashboard/rest-api.mdx`:
- Around line 13-17: Update the route authentication documentation to qualify
`/readiness` and `/metrics` as exempt from session authentication only when
their configured metrics-token requirements are satisfied; clarify that
sessionless requests alone may be rejected when metrics-token protection is
enabled.
In `@docs/content/docs/python/guides/dashboard/task-overrides.mdx`:
- Around line 59-78: Update the table’s “Paused” description to clarify that
task pause has no decorator equivalent and is persisted or exposed as metadata,
but is not enforced by the scheduler. Align the wording with the
`queue.set_task_override(..., paused=True)` behavior described in the
task-overrides section, avoiding the inaccurate “runtime-only” label.
In `@docs/content/docs/python/guides/integrations/fastapi.mdx`:
- Around line 64-67: Update the FastAPI integration documentation around
require_api_key to explicitly state that the x_api_key parameter maps to the
wire header name x-api-key by default; mention convert_underscores=False only if
documenting the underscore-form header instead.
In `@docs/content/docs/python/guides/operations/testing.mdx`:
- Around line 158-176: Make the test_chord example self-contained by defining a
local double task before it is used, or replacing double with an inline minimal
task, while preserving the expected group results and callback assertion.
In `@docs/content/docs/python/guides/reliability/rate-limiting.mdx`:
- Around line 8-9: Update the rate-limiting documentation near the description
of persisted rate limits to include Redis alongside SQLite and Postgres. Ensure
the backend list accurately states that rate-limit state is persisted in SQLite,
Postgres, or Redis.
In `@docs/content/docs/python/guides/reliability/retries.mdx`:
- Around line 152-164: Update the retry example to wait for task completion by
calling job.result() and catching its final exception before iterating over
job.errors; retain the existing attempt-printing logic and clarify that errors
are read only after completion.
In `@docs/content/docs/python/guides/resources/testing.mdx`:
- Around line 12-14: Qualify the parallel-safety statement for test_mode():
explain that parallel use is safe only when tests use separate Queue instances,
since overlapping contexts sharing a queue can interfere through queue-level
state and enqueue patching. Update the surrounding documentation accordingly.
In `@docs/content/docs/python/more/examples/workflows.mdx`:
- Around line 64-65: The example defines accuracy_gate but does not use it,
leaving deploy behind a manual review gate instead of evaluate’s passed result.
Update the workflow construction to register accuracy_gate through
wf.gate("review", ...) and ensure deploy depends on that gate, removing the
manual gate configuration while preserving the ctx.results-based evaluation
flow.
In `@docs/content/docs/resources/comparison.mdx`:
- Line 142: Update the GIL row in the comparison table to clarify that Rust
avoids GIL contention only during scheduling and dispatch, while worker threads
still acquire the GIL when executing Python task code; revise the Rust-side
wording accordingly without changing the Python-side comparison.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
is_terminal() includes CompletedWithFailures; the saga wait table said five.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/content/docs/python/guides/resources/dependency-injection.mdx (1)
212-219: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winHealth-check example still creates an engine with no disposal path.
create_db()here returnssessionmaker(create_engine(...))with noteardownparameter, unlike the "Teardown" section above it. This is exactly the pattern the earlier review flagged ("Also applies to: 209-216") — and it's arguably more important here, sincemax_recreation_attemptsimplies this factory can be invoked multiple times to recreate the resource after health-check failures. Without ateardown, each recreation leaks the previous engine's connection pool. Add the sameteardown=lambda db: db.kw["bind"].dispose()wiring used in the Teardown section (or the engine-reference alternative suggested above) so copy-pasting this example doesn't leak connections.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/guides/resources/dependency-injection.mdx` around lines 212 - 219, Add a teardown handler to the create_db resource example, passing teardown=lambda db: db.kw["bind"].dispose() to queue.worker_resource so each recreated sessionmaker disposes its bound engine; keep the existing health-check and recreation settings unchanged.
🧹 Nitpick comments (1)
docs/content/docs/python/guides/resources/dependency-injection.mdx (1)
172-173: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winAvoid
sessionmaker.kw["bind"]in the teardown example
kwis an internal implementation detail, so keep the engine reference explicit and dispose that instead.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/content/docs/python/guides/resources/dependency-injection.mdx` around lines 172 - 173, Update the dependency-injection teardown example to avoid accessing the sessionmaker’s internal db.kw["bind"] in the teardown lambda. Keep the engine reference explicit when configuring the resource and use that reference in the teardown callback to call dispose().
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/app/components/mermaid.tsx`:
- Around line 17-19: Focus restoration in the zoom overlay uses
triggerRef.current after it has been cleared, so closing cannot restore focus.
Update the zoom/open click handler to capture the triggering button element
before setting zoomed, store it in a stable ref, and have the zoomed effect
cleanup focus that saved element instead of relying on triggerRef.current.
---
Outside diff comments:
In `@docs/content/docs/python/guides/resources/dependency-injection.mdx`:
- Around line 212-219: Add a teardown handler to the create_db resource example,
passing teardown=lambda db: db.kw["bind"].dispose() to queue.worker_resource so
each recreated sessionmaker disposes its bound engine; keep the existing
health-check and recreation settings unchanged.
---
Nitpick comments:
In `@docs/content/docs/python/guides/resources/dependency-injection.mdx`:
- Around line 172-173: Update the dependency-injection teardown example to avoid
accessing the sessionmaker’s internal db.kw["bind"] in the teardown lambda. Keep
the engine reference explicit when configuring the resource and use that
reference in the teardown callback to call dispose().
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 62e147a0-62d9-49f5-8cf1-edb31383d76f
📒 Files selected for processing (10)
docs/app/components/mermaid.tsxdocs/content/docs/java/guides/operations/backends.mdxdocs/content/docs/node/guides/operations/migration.mdxdocs/content/docs/node/guides/operations/security.mdxdocs/content/docs/node/guides/reliability/guarantees.mdxdocs/content/docs/python/api-reference/saga.mdxdocs/content/docs/python/getting-started/concepts.mdxdocs/content/docs/python/guides/reliability/guarantees.mdxdocs/content/docs/python/guides/resources/dependency-injection.mdxdocs/content/docs/python/guides/resources/proxies.mdx
✅ Files skipped from review due to trivial changes (6)
- docs/content/docs/java/guides/operations/backends.mdx
- docs/content/docs/node/guides/operations/migration.mdx
- docs/content/docs/python/api-reference/saga.mdx
- docs/content/docs/node/guides/operations/security.mdx
- docs/content/docs/python/guides/reliability/guarantees.mdx
- docs/content/docs/python/getting-started/concepts.mdx
🚧 Files skipped from review as they are similar to previous changes (2)
- docs/content/docs/python/guides/resources/proxies.mdx
- docs/content/docs/node/guides/reliability/guarantees.mdx
1 participant
Summary
Content audit and remediation across the Fumadocs site — accuracy fixes to the SDK docs, a landing page rework, and docs UI/theming polish (~46 commits).
Content accuracy fixes
Audited and corrected Python, Node, and Java SDK docs — getting-started, core / reliability / workflows / operations / resources / observability guides, API reference, and examples. Fixed stale examples, incorrect params, and inaccurate behavior descriptions flagged during the audit (serializer defaults, delivery semantics, no-broker architecture, worker startup, CLI, task params/status, dedup/retries/timeouts, mesh, migration, dashboard routes).
Landing page rework
Docs UI / theming
Test plan
Summary by CodeRabbit